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ABSTRACT 



A serial to parallel port signal converter for interconnection 
between a hosts utilizing Uniform Serial Bus communica- 
tions protocols and a peripheral device uses IEEE 1284 
complaint communications protocol. The signal converter 
appears to the host as a fully compliant bi-directional USB 
device, and to the peripheral device as a fully compliant 
IEEE 1284 host. 
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UNIVERSAL SERIAL BUS TO PARALLEL . transmission of a byte of information in both directions 

BUS SIGNAL CONVERTER AND METHOD between the host computer and the printer. 

OF CONVERSION The vast majority of printers of whatever type, make and 

manufacture, that are in use and are currently being manu- 

This application is a continuation of Ser. No. 08/974,736 5 factured in the United States, are for use with one or more 

filed Nov. 19, 1997. of these communications protocols in conjunction with a 

parallel port conforming to the IEEE 1284 standard. 

BACKGROUND OF THE INVENTION Other computer peripherals, including document scanners 

1 Technical Field anc ^ peripteral memory storage devices, also utilize the 

. . , A . ^ r 10 parallel port conforming to the IEEE 1284 standard, and 

This mvention generally relates to a agnal converter for ^ municatioas * rotocols . However, because of the 

converting signals transmitted from a Universal Serial Bus m requirements, there may be additional protocols 

conforming to standards, as implemented by the Universal ^ J Q ^ ^ ^ [n the host wfaicfa afe 

Serial Bus Implementation Fomm to signals transmitted ^ m tibim mod enhanced capabilities 

from a parallel port conforming to IEEE Standard 1284 and 15 mod 0f in ^ extecded Ud mode 

the reverse. ^ . , _ . , _ , . . _ 

The Universal Serial Bus, USB, communication protocol 

2. Background ^ d iff erent [ Q fundamental areas, not the least of which 

Throughout its history, the computer and computer jg rjSB is a serial communications protocol, which is 

peripheral electronics industry has made a continuing effort designed around shift registers. As a result, it is not possible 

to standardize input/output ports and signal or communica- 20 to connect the input/output, I/O, USB port to a device 

tion protocols. This has been, in large part, accomplished by designed to receive and transmit data through an I/O parallel 

adoption and adherence to industry standards such as those port conforming to the IEEE 1284 standard. Accordingly, 

set forth by the Institute of Electrical and Electronic Engi- wnat ^ needed is a device which can be used to connect a 

neers (IEEE). USB ported host to a peripheral as a parallel ported, IEEE 

A number of computer peripherals, including most print- 25 1284 conforming, host. It is one object of this invention to 

ing devices, some paper and photograph scanners, and also provide a converter which can operate in an automatic mode 

some peripheral memory storage devices, are designed for as a fully compliant USB device receiving and sending data 

interconnection to a host computer through the standard, and using USB communications protocols, and as a 

well known parallel port connector which conforms to the re -transmitting device sending and receiving data to an 

IEEE 1284 standard as adopted in the fall of 1994. 30 attached peripheral device as a fully compliant parallel port 

With printers, the typical information flow and processing device, all done in a transparent manner wherein that the 

steps can be demonstrated by simple example as follows: host need have no knowledge that the protocol translation is 

The document to be printed is first generated in the host occurring. 

computer using information processing application 35 It is another object of this invention to provide a signal 
software, such as a word processing, or a spread sheet, converter which can operate in a register mode wherein the 
program. The document, in the form of an electronic file of signal converter contains a set of registers which emulate 
information, is then processed in a second software program, those found in standard computer parallel port hardware, 
usually called a printer driver, where the information from cmjru A1>v nT7 TOT7 thIV ow-rinw 
the original application file is converted into a string of data 4Q SUMMARY OF THE INVENTION 
bits which will ultimately be used by the printer to generate These objects are accomplished in a serial to parallel port 
pixels in the complete dithered printed image. The printer signal converter which is preferably manufactured as a 
driver software will perform such functions as scaling of one-chip serial to parallel port signal converter which con- 
pixels, addressing, adding color data, and often times even verts a bit stream signal coming from the universal serial bus 
compressing the data in the event of redundant data. 45 0 f a host device to a parallel signal conforming to the 

This data stream is then passed through a third, lower Institute of Electronic and Electrical Engineers (IEEE) 1284 

level driver software application, usually the operating sys- signal protocol. It is connected to, and appears to a universal 

tern software, where it is assembled into bytes suitable for serial bus (USB) of a host, as a standard USB device, and to 

transmission through the host computer's parallel port to the a peripheral device as an IEEE 1284 host. It operates in two 

computer peripheral, which in this example is a printer. Over 50 different modes, the first being the automatic mode wherein 

the years, a number of communication protocols have been it acts as a fully compliant bi-directional USB device 

developed for use in communication between the host receiving USB data packets and retransmitting that data to 

computer and the printer peripheral. The earliest and sim- the attached peripheral device transparently as if it were an 

plest of these protocols is known as the compatibility mode IEEE 1284 host. In automatic mode, the actual host device 

protocol, in which data is sent from the host computer to the 55 has no knowledge that the protocol translation is occurring, 

printer in one direction only, in eight bit, or one byte, parallel In the second mode, register mode, the signal converter 

format. A more advanced version of compatibility mode contains a set of registers which emulate those found in 

includes what is known as the NIBBLE mode protocol standard, IEEE compliant parallel port hardware, 

which provides or allows specific information to flow back The serial to parallel port signal converter can be under- 

from the printer to the host computer over dedicated pins of 60 stood representationally as a series of modules, the first 

the parallel port, four bits at a time, and enables the printer being the universal serial bus device controller module 

to report to the host computer status conditions. which is connected to the universal device controller 

Still later, the Extended Capabilities Port (ECP) protocol interface, a buffer memory, a read-only memory, and a 

was developed wherein eight bits, one byte, of information parallel port interface module. The universal serial bus 

can flow in either direction between the host computer and 65 device controller is an application specific standard product 

the peripheral printer. Another protocol, known as the developed by Sand Microelectronics, Inc., and available 

Enhanced Parallel Port (EPP) protocol permits simultaneous from Lucent Technologies and is known by the macrosell 
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name of UDC as published in the Lucent Technologies 
System ASIC data book dated September, 1996. It functions 
as a controller for managing signals to and from the uni- 
versal serial bus of the host, including generation and 
transmission of start codes, data strobes, and control and 
data signals. It handles most of the low level USB protocol 
operations and converts USB bit streams of data to a stream 
of bytes, plus control and status information. It is used to 
separate the cyclical redundancy check signal from the data, 
while it keeps the data in a register and verifies the accuracy 
of the cyclical redundancy check signal, and is used to send 
acknowledgment or non-acknowledgment signals to a uni- 
versal device controller interface. The universal serial bus 
device controller also performs an additional function in that 
it stores the information about the end points of data streams 
and the devices supported by the serial to parallel port signal 
converter. 

A universal device controller interface is provided and is 
utilized as a control device for the universal serial bus device 
controller, adding support for the USB protocol features not 
handled directly by the universal serial bus device controller. 
Some of these additional features include decoding of 
descriptor requests, and providing of descriptor data, which 
is sourced by the read-only memory by way of a buffer 
memory. It also provides support for all printer class device 
commands and support which is unique and specific to the 
present invention and not part of any standard specification. 
The universal device controller interface has ports for com- 
municating to the buffer memory and also a port for com- 
municating directly with the parallel port interface module. 

A buffer memory is provided and is a block which has 
byte -oriented storage for multiple data packs, which in the 
preferred embodiment are packets of sixty-four (64) bytes. 
There are independent input and output channels for two 
packets of one hundred twenty eight (128) bytes of actual 
value in each direction. 

The parallel port interface module is made of hardware 
for a fully automatic support of Institute of Electronic and 
Electrical Engineers (IEEE) 1284 standardized 
compatibility, NIBBLE, extended capability port and 
enhanced parallel port with and without run length encoded 
communications modes. It is intended to emulate normal 
parallel port hardware such as might be implemented with 
an industry standard super-I/O chip. It also includes logic to 
provide control for the automatic and register based parallel 
port logic, including readable and writeable registers which 
emulate those found in standard personal computers. It also 
includes necessary support logic, such as timers, counters, 
digital filters and post stretchers. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a high level block diagram of the serial bus to 
parallel bus signal converter; 

FIGS. 2 A through 2D is a flow chart block diagram of the 
universal device controller interface; 

FIG. 3 is a state transition diagram for the universal 
device 

FIG. 4 is a block diagram flow chart of the data write 
operations of the buffer; 

FIG. 5 is a block diagram flow chart of the data read 
operations of the buffer; 

FIG. 6 is a high level block diagram of the parallel port 
interface module. 

FIG. 7 is a flow chart block diagram of the parallel port 
interface module; 
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FIG. 8 is a state transition diagram for the controller 
operations of the parallel port interface module; 

FIG. 9 is a state transition diagram for the master state 
machine operations of the parallel port interface module; 
5 FIG. 10 is a state transition diagram of the operations of 
the compatibility mode host for the parallel port interface 
module; 

FIG. 11 is a state transition diagram of the NIBBLE mode 
1Q host of the parallel port interface module; 

FIG. 12 is a master state transition diagram of the ECP 
host operations of the parallel port interface module; 

FIG. 13 is a diagram of the ECP host in register mode 
operations of the parallel port interface module; 
15 FIG. 14 is a state transition diagram of the EPP host 
operations in register mode operations for the parallel port 
interface module. 

DESCRIPTION OF THE PREFERRED 
20 EMBODIMENT 

The serial to parallel port signal converter 10 of the 
present invention is shown in a high-level block in FIG. 1. 
It is preferably manufactured as a one-chip serial to parallel 
port signal converter which converts a bit stream signal 

25 coming from the universal serial bus of a host device to a 
parallel signal conforming to Institute of Electronic and 
Electrical Engineers (IEEE 1284) signal protocol. It is 
connected to, and appears, to a universal serial bus of a host, 
hereinafter USB, as a standard USB device, and to a 

30 peripheral device as an IEEE 1284 host. It operates in two 
different modes, the first being the automatic mode, wherein 
it acts as a fully compliant bi-directional USB device 
receiving USB data packets and retransmitting that data to 
the attached peripheral device transparently as if it were a 

35 IEEE 1284 host. In automatic mode, the actual host device 
has no knowledge that the protocol translation is occurring. 

In the second mode, register mode, the signal converter 
contains a set of registers which emulate those found in 

4Q standard, IEEE 1284 compliant parallel port hardware. 

As shown in FIG. 1, the serial to parallel port signal 
converter 10 can be shown representationally as a series of 
modules, the first being the universal serial bus device 
controller module 12 to which is connected the universal 

45 device controller interface 14, buffer memory 16, read only 
memory 18, and parallel port interface module 20. The 
universal serial bus device controller 12 is, in the preferred 
embodiment, an application specific standard product devel- 
oped by Sand Microelectronics, Inc., and available from 

5 q Lucent Technologies®, and is known by the MACROCELL 
name of UDC as published in the_Lucent Technologies 
System ASIC Data Book dated September, 1996. 

Universal serial bus device controller 12 is known in the 
prior art and its functions play no part of the present 

55 invention, except as a controller for a managing signals to 
and from the universal serial bus of the host in the manner 
which is hereinafter generally described. 

Universal serial bus device controller 12 is used in the 
present invention to generally manage the USB data 

60 transmission, either to or from the host, including generation 
and transmission of start codes, data strobes and control and 
data signals. It handles most of the low level USB protocol 
operations and converts USB bit streams of data to a stream 
of bytes, plus control and status information. It is used to 

65 separate the cyclical redundancy check signal from the data, 
while it keeps the data in a register and verifies the accuracy 
of the cyclical redundancy check signal, and is used to send 
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acknowledgment or no a- acknowledgment signals to the 
universal device controller interface 14. 

This is accomplished in the universal serial bus device 
controller 12 by a series of blocks, not shown in the 
diagrams, which include a phase lock loop for synchronizing 
the clock signals of universal serial bus device controller 12 
and the entire serial to parallel port signal converter 10 to the 
clock signals of the host, and a serial interface engine which 
does the initial functions of the USB protocol: syncField 
identification, NRZI-NRZ conversion, token packet 
decoding, bit stripping, bit stuffing, NRZ-NRZI conversion, 
CRC5 checking and CRC 16 generation and checking. It 
also converts the serial packets from the USB signal to 8 bit 
parallel data. The universal serial bus device controller 12 
also performs an additional function in the preferred 
embodiment, in that it stores the information about the end 
points and the devices supported by the serial to parallel port 
signal converter 10. 

The universal device controller interface is utilized as a 
control device for the universal serial bus device controller, 
adding support for the USB protocol features not handled 
directly by the universal serial bus device controller 10. 
Some of these additional features include decoding of 
descriptor requests and providing of descriptor data, which 
is sourced by the ROM 18 by way of buffer memory 16, and 
also provides support for all printer class device commands 
and support which is unique and specific to the present 
invention and not part of any standard specification. Uni- 
versal device controller interface 14 has ports for commu- 
nicating to the buffer memory and also a port for commu- 
nicating directly with the parallel port interface module 20. 

Buffer memory 16 is simply that, in that it is a block 
which has byte-oriented storage for multiple data packets, 
which in the preferred embodiment are packets of sixty four 
bytes. There are independent input and output channels, with 
buffering for two packets of 128 bytes of actual value in each 
direction. 

Read only memory, ROM, 18 stores the specifications and 
information necessary to convert descriptor data from one 
communications protocol to another, as is hereinafter 
described. 

The parallel port interface module 20 is made up of 
hardware for fully automatic support of Institute of Electri- 
cal and Electronic Engineers (IEEE) 1284 standardized 
compatibility, NIBBLE, extended capability port (ECP) and 
enhanced parallel port (EPP) with and without run length 
encoded (RLE) communications modes, and is intended to 
emulate normal parallel port hardware, such as might be 
implemented with an industry-standard super-I/O chip. It 
also includes logic to provide control for the automatic and 
register based parallel port logic, including readable and 
write able registers which emulate those found in standard 
personal computers. It also includes necessary support logic 
such as timers, counters, digital filters and pulse stretchers, 
as is hereinafter described. 

FIGS. 2A through 2D, a flow diagram, illustrate the 
actions taken in the universal device controller interface 14. 
In the first step, a data input is initiated in block 30 from the 
universal serial bus device controller 12, after which in 
decision block 32, a decision is made as to whether a data 
transfer has been initiated. If no data transfer is initiated, the 
universal device controller interface continues to wait for the 
initiation of a transfer, as is also shown in circle 31 of state 
transition diagram, FIG. 3. 

Once a transfer is initiated, the transfer is decoded in 
Block 34 to identify the type of data being transmitted, as 
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either being a command packet, in which case it is trans- 
ferred to block 36, and interrupt request packet which is 
ported to block 38, or a data packet which is sent to block 
40. 

5 As shown in FIG. 3, once a transfer is initiated, universal 
device controller 14 transitions to a set up state as shown in 
circle 31 wherein the data from the USB host coming 
from__universal serial bus controller is loaded into an appli- 
cation bus. The completion of the receipt of data acknowl- 

10 edgment signal (ACK) or a not-acknowledged signal 
(NACK) transitions universal device controller interface 14 
back to the idle state as shown in circle 31. If the data loaded 
during the set up, shown in circle 33, is a command packet, 
the universal device controller interface 14 transitions to the 

15 CONTROL_IN state as shown in circle 35 as the command 
is decoded. And its transfer is either acknowledged or not 
acknowledged. If it is not acknowledged, the universal 
device controller interface returns to idle state 31. 

If the data is a command packet, as shown in FIG. 2B, the 

20 command packet is then decoded in block 42 and, in 
decision block 44, a decision is made as to whether it is a 
valid transfer of command packet data. In this decision 
block, an acknowledgment signal (ACK) or a not acknowl- 
edged signal (NACK) is received from the universal serial 

25 bus device controller, either acknowledging or not acknowl- 
edging the receipt of the valid cyclical redundancy check, 
(CRC) signal. If the decision is no, the proper acknowledg- 
ment has not been received, then the universal device 
controller interface resets to decision block 32 to await a 

30 valid transfer initiation. 

If a valid acknowledgment is received, as determined by 
decision block 44, then a decision is made as to whether or 
not the command signal indicates that the host device 

35 requires that data be sent back to the host device regarding 
status information of the peripheral to which the parallel port 
interface module 20 is connected. This is also shown in the 
state transition diagram of FIG. 3 as state 37. If the answer 
is no, no status data is required, or no CONTROL_OUT 

40 transfer is received a decision is made in decision block 48, 
to send a stall handshake. If the decision is yes, and the 
signal has been received, then in block 62 a signal of a valid 
transfer is initiated back to the universal serial bus device 
controller 12. If the answer in decision block 48 is no, that 

45 is to say that a CONTROL_IN was not expected, then in 
box 50, there is sent a stall handshake back to the universal 
serial bus device controller 12 and the universal device 
controller transitions back to idle state shown as Circle 31 in 
FIG. 3. 

50 If, as determined in decision box 46, data is required by 
the host, then, in decision box 52, the universal device 
controller interface 14 awaits for the receipt of a 
CONTROL_IN transfer indicating that the host is ready to 
receive the requested status data from the peripheral device 

55 as it transitions to the CONTROUN__state of circle 35 of 
FIG. 3. As shown in block 54, the data is sent to the host and 
the universal device controller interface 14 awaits, in deci- 
sion block 56, an acknowledgment that the transfer was 
received by the host. If, in decision block 52, it is determined 

60 that no_CONTROL__IN transfer is received, or a 
CONTROL_OUT transfer is received, then as shown in box 
50, a stall handshake is sent in the same manner as if a 
CONTROL— IN transfer was not included in the status for a 
command not requiring return data or the status transfer in 

65 the command was a CONTROL__OUT. 

Once the data has been sent to the host in state 39 of FIG. 
3_and in block 54 of FIG. 2, universal device controller 
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interface 14 awaits, in decision block 56, receipt of an embodiment, each byte of information is treated and pro- 
acknowledgment of the transfer. If acknowledgment is cessed separately. If the answer in decision box 82 is yes, 
received, in block 62, the universal device controller inter- there is a location available to write a byte of information, 
face signals a valid transfer. If the transfer acknowledgment then in box 84 an ASSERT DATA_IN signal is sent to 
is not received, then as shown in block 60, the device signals 5 universal device controller interface 14 acknowledging that 
an invalid transfer there ^ a s P ace available. Once the signal is sent, then buffer 
. , . . ' . . ., - „ _ - , . „„ -„ ., memory 16 waits, at decision box 86, to receive the DATA_ 
As shown in stole circle 43 of FIG. 3, and m FIG. 2C if , N Qn<x , he rjATA IN request is received as 
the data identified in block 34 is an interrupt request packet shown 4 in decision feox g6 tD6 ~ emi ^ s described m box gg 
m block 38 of FIG. 2A, a decision is made m decision block name , ^ data fa ^ ^ buffef m u and 
50 whether the requested data is available, ".the answer is to ^ fc ^ ^ ^ fe incremcDted t0 the n6Xt b te 
yes, as shown in circle 41 of FIG. 3 and then in block 52 of jn ^ ^ffe/njenorTand buffer memory 16 then waits for 
FIG.2 hedataKsentthrou^theumversalsenalbusdevice an acknowledgmen / mat ,h e transfer * completed in deci- 
controller 12 to the host and then awaits in decision block sfon ^ and ^ fc recejved theQ as shown in box 92) 
54, for an acknowledgment of receipt of the transferred data. me startfag ^ pointer fc updated , 0 ma , ch the temporary 

If the data transfer is acknowledged, the universal device 15 pointer 

controller interface then signals thata valid ^fcr has Jn ^ event bq transfer , ^ received 

oc^rred and resets m decision block 60. If m decision block din the DAT a IN signal, then in decision box 94 a 

50 it is determined that the requested data is not available, ^ ackn * wled ^ (nAC K) signal regarding receipt of the 

then a not acknowledged handshake packet signal is sent o * * 4^ io & x 9< p the temporary 

Tl 61 *? bUS T . •? 1, ultimately to 20 - ? h ^ ^ yaluc 

the host. If the requested data was available and was sent in y L L 

box 52, and no acknowledgment is received in decision box In lhe event ™ 1™*™ * f ™ oJ 1 ^ the byt6 

54, then as is shown in box 58, the universal device of data, then as shown in box 98, a DE_ASSERT data input 

controller interface 14 signals an invalid transfer and the acknowledgment signal is sent. 

device resets. How data is read from buffer memory 16 is shown in the 

If the data transfer initiation identified in box 34 indicates 25 flow chart of FIG. 5. First, in decision box 100, a decision 

that it is a data packet, then in decision box 62, as shown in is made as to whether the data byte is available for read. If 

FIG. 2D, a decision is made as to whether it is a BULK_ the answer * Y es > then 10 box 102 an ASSERT DATA_OUT 

OUT packet of data from the host or a BULK_IN data request is made, and in decision box 104 a decision is made 

packet to be sent from the universal device to the host in as to whether or not the ASSERTED DATA_OUT request 

which case universal device controller interface transitions 30 is acknowledged. If not, buffer memory 16 waits for its 

to the BULK_OUT__or the BULK__IN state shown in receipt. Once it is received, then in box 106 the data is 

circles 39 and 41 of FIG. 3, as the case may be. retrieved from the buffer and the temporary read pointer is 

IfitisaBULK OUT packet, and the decision in decision t0 l t h f nex f l ^ Afteiwaids, i? decision box 

box 62 is no, therTin decision box 64 the decision is made 108 > the data out transfer acknowledgment is .waited and 

as to whether there is sufficient storage space in the buffer to 35 upon receipt, in box 110, the starting read pointer is updated 

receive the data. Data packets are Transferred through the to match the temporary read pointer, 

universal serial bus device controller 12 in eight bit bytes, If the data out transfer acknowledgment is not received, 

one at a time. As each byte is received, the decision is made then in decision box 112 a data out transfer is not 

concerning space availability in decision box 64. If the acknowledged, nACK, is sent and in box 114 the temporary 

decision is yes, then the data is sent to the buffer for storage, 40 read pointer is reset to its starting value, 

as shown in box 66. If the decision is no, a not acknowledged In the event that data is not available for read as deter- 

handshake packet is sent as shown in box 68. Once the data mined in decision box 100, then a DE_ASSERT DATA_ 

is received and sent to the buffer in box 66, a decision is OUT request is made in box 116. 

made in decision box 70 as to whether an acknowledgment r n piG. 6 there is shown and described a high level block 

is received for the data. If the answer is yes, then in box 72 4S diagram for the parallel port interface module 20. At the 

the universal device controller interface 14 signals a valid neart 0 f parallel port interface module 20 is controller 126, 

transfer. which is used to control, through master state machine 128, 

If the decision in decision box 62 is that the data is a compatibility mode protocol host 130, NIBBLE protocol 

BULK_IN packet which is data received from the periph- host 132 and extended capabilities port host 134. A digital 

eral for transfer to the host in response to an interrupt 5Q filter 144 5 is provided for incoming signals. It is optionally 

request, then in decision box 74, a decision is made as to used to filter spurious or false signals by holding and not 

whether the data is available in the buffer. If it is not, then passing on each signal until a predetermined number of 

a not acknowledged (nACK) handshake packet is sent to the clock ticks occur, thus assuring that all signals inputted to 

universal serial bus device 12. If the answer is yes, then in parallel port interface module 20 are true signals. Also 

box 76 the data is retrieved from the buffer, and in box 78 provided, as shown in the block diagram of FIG. 6 there is 

is sent to the host, and in decision box 70 a decision is made 55 an extended parallel port register host 136 and extended 

as to whether or not an acknowledgment is received for the capabilities port register host 138. Control registers 142 are 

data sent. If the answer is yes, then in box 72 the interface provided. One shot 146 generates a fixed pulse signal to 

14 sigrjals a valid transfer and if the answer is no, then as transition the parallel port interface module 20 output to 

shown in box 80, the signal is for an invalid transfer. high drive by generation of a fixed pulse signal. 

FIG. 4 is a flow chart showing how data is written into 60 FIGS. 7Aand 7B represent a flow chart for the operations 

buffer memory 16 in response to the operation shown in of_parallel port interface module 20, as shown in FIG. 6. 

FIG. 66 of FIG. 2D when data is sent to. the buffer. The parallel port interface module 20 attempts to commu- 

Asdata is sent to buffer memory 16 as shown in block 66 nicate with the peripheral device in the highest, or most 

of FIG. 2D, the first decision made in buffer memory 16 is advanced, communication protocol that the peripheral 

as shown in decision box 82 of FIG. 4. The decision made 65 device is capable of using. It uses a hierarchle order of the 

is whether there is a location available for writing the next IEEE 1284 communications protocol, starting with the most 

byte of information. In the buffer, in the preferred advanced communications protocol, and stepping down 
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through hierarchle until it establishes communications with 
the peripheral device. 

As seen in FIGS. 7A and 7B, data from the buffer 16 is 
received through the parallel port interface module 20 
through data transfer box 151. As it is received, the first 
decision is made in decision box 153 is whether data from 
the host is available. If the answer is no, then parallel port 
interface module 20 remains in an idle state. If the answer 
is yes, then a decision is made in decision box 155, is there 
a DEVICE_ID command in the data that is available. The 
DEVICE_ID command is the result of the translation of a 
USB command protocol entitled GET DEVICE_JD which 
is the USB command protocol command which requests 
data from the peripheral regarding the identification of the 
manufacturer of the peripheral device, the type of device it 
is, and what communications protocols the peripheral sup- 
ports. The GET DEVICE_ID command is very similar to 
the DEVICE_IN command of the extended communication 
port communications protocol utilized by devices which are 
compliant with IEEE 1284 specifications. As a result, as 
shown in FIGS. 2A through 2D, the USB GET DEVI CE_ID 
command of the USB protocol is translated into a 
DEVICE_JD command. If the answer in decision box 155 
is yes, then in box 157 an attempt is made to send the 
DEVICE_ID command to the peripheral using extended 
capabilities port protocols with run length encoding. A 
decision has been made in decision box 159 as to whether 
the peripheral device communicates in extended capabilities 
port protocol with run length encoding._If the answer is 
yes, then in box 169 the command, and later data, is sent in 
extended capabilities port protocol with run length 
encoding, and periodically a TRY_REVERSE command is 
sent in extended capabilities port protocol and NIBBLE. If 
the answer is no, then in box 161 the parallel port interface 
module 20 will try the DEVICE__ID command using 
extended capabilities port protocol without run length 
encoding. If communication is established in extended capa- 
bilities protocol as shown in decision box 163, then in box 
171 data is then sent to the device in extended capabilities 
protocol and the parallel port interface module 20 periodi- 
cally tries reverse communication in extended_capabilities 
protocol and_NIBBLE. 

If the answer in decision box 163 is no in that the device 
does not use the extended capabilities communications 

protocol, then in decision box 165 a decision is made as to 

whether there exists a protocol error. If the answer is yes, 
then data is sent as shown in box 173 in the compatibility 
mode and the device periodically tries NIBBLE. 

If the answer in decision box 165 was no, there was no 
protocol error, then in box 167 parallel port interface module 
tries the DEVICE_ID command using NIBBLE. Irrespec- 
tive of whether the device does or does not use NIBBLE, 
parallel port interface module 20 will begin to send data in 
the compatibility mode as shown in box 173 and will 
periodically try NIBBLE irrespective of whether or not the 
DEVICE_ID command indicated that the device used it. 

If it is determined in decision box 155 that the incoming 
data does not contain a DEVICE_JD command, then in box 
177 a decision is made as to whether the incoming data is 
enhanced capabilities protocol encoded with run length 
encoding. If the answer is yes, then the data will be sent as 
shown in box 169 in extended capabilities protocol with run 
length encoding and parallel port interface module 20 will 
periodically try reverse in capabilities protocol and in 
NIBBLE. If it is determined in decision box 177 that there 
is no run length encoding, then in decision box 179 the 
decision is made as to whether or not a protocol error has 
occurred. If the answer is yes, then the data is sent as shown 
in box 173 in the compatibility mode. If the decision in box 
179 is no, then a determination is made in decision box 181 
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as to whether the data is in extended capabilities protocol 
encoded without run length encoding. If the answer is yes, 
then data is sent in capabilities protocol and the parallel port 
interface module 20 will periodically try reverse in extended 

5 capabilities protocol and NIBBLE. If the decision in deci- 
sion box 181 is no, then the data is sent in the compatibility 
mode and the parallel port interface module will periodically 
try to communicate with the device in NIBBLE. 
In each case, whether the data is being sent in extended 

1Q capabilities protocol with run length encoding, or without it, 
or if it is being sent in compatibility mode, the parallel port 
interface module 20 will periodically attempt to run reversed 
so as to receive data from the device. This is shown in 
decision boxes 183, 185 and 187. If the decision is yes, then 
in box 189 the data is sent to the buffer through transfer box 

15 191. 

Next, there is shown in FIG. 8 a state transition diagram 
of the operations of controller 126 of FIG. 6 for the parallel 
port interface module 20. As previously stated, signal con- 
verter 10 can support three of the basic communications 

20 protocols used with a parallel port I/O device conforming to 
the IEEE 1284 standard. These are: the compatibility mode 
protocol; the extended capabilities port (ECP) with or with- 
out run length encoded (RLE) compression protocol; and the 
enhanced parallel port protocol (EPP). As shown in circle 

25 150 of FIG. 8, the power up state is idle and the parallel port 
interface module 20 is in compatibility mode. This is the 
default in which the parallel port interface module 20 will 
initially start. 

After starting in compatibility mode protocol, controller 

30 126 will attempt to change states to the highest level 
protocol available, which, in the preferred embodiment, in 
automatic operation is extended capabilities port (ECP) 
protocol with run length encoding. If the peripheral device 
will communicate using this protocol, controller 126 passes 
to the forward state shown in circle 156 wherein the parallel 
port interface module 20 will communicate and pass data to 
the peripheral device using extended capabilities port pro- 
tocol with run length encoding. In the event that the periph- 
eral device cannot communicate in this protocol, then the 
parallel port interface module 20, controller 126 will attempt 

40 to communicate with the peripheral device utilizing the next 
highest protocol available, which is extended capabilities 
port protocol as shown in state 154. If the peripheral device 
can communicate in this state, the machine passes into the 
forward state shown in circle 156 wherein it again begins 

45 sending data to the peripheral device using extended com- 
munications port protocol without run length encoding. If 
the attempt to communicate using extended communications 
port protocol fails because the peripheral device is not 
configured to communicate in that protocol, controller 126 

50 shifts into the forward state of 156 utilizing the default 
protocol, namely the compatibility mode protocol. 

If in the attempts to use the higher level protocol 
languages, controller 126 for the parallel port interface 
module detects either that the peripheral device is not IEEE 

55 1284 compliant, or that there is a protocol error, it will 
automatically shift into the forward transmission state 
shown in circle 156 utilizing the lowest level protocol 
language, namely the compatibility mode. 

One of the initial command packets that will be sent by 
the host device utilizing USB command protocols is the 

60 command G ET_DE VI CE_I D which is a command which 
requests data from the peripheral regarding the name of the 
manufacturer of the peripheral device, the type of device it 
is, and what communication protocols the peripheral sup- 
ports. This command is very similar to the DEVICE ID 

65 command utilized by devices which are compliant with 
IEEE 1284 specifications. As a result, the GET_DEVICE_ 
ID command of the USB protocol is translated into a 
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DEVICE_ID command. If the GET_DEVICE_ID com- 
mand is received, then in parallel port interface module 20, 
controller 126 will attempt to try the DEVICE_ID and 
command using extended capability port communications 
protocol as shown in state circle 158. If it fails in state 158, 
or if there is a protocol error, it will attempt again to try the 
DEVICE_ID command in the NIBBLE communication 
protocol as shown in state 160. If this fails, the controller 
shifts into forward state 156. 

If either the first attempt to communicate the DEVICE_ 
ID command using ECP, (extended capabilities port) or the 
attempt to communicate it using the NIBBLE protocol 
succeeds, then controller 126 passes into the state shown in 
circle 162, namely, the receipt of the DEV1CE_ID string 
from the peripheral device in either Extended Communica- 
tion Port (ECP) or NIBBLE protocols, whichever first 
worked. And finally, after receiving the strings, controller 
126 enters a state shown in circle 164, namely the signaling 
of the end of the DEVICE_ID transfer, and a return to the 
default state of 150, namely the idle state. 

During forward state operations as shown in circle 156, 
when operating in ECP, the controller will periodically issue 
a TRY_REVERSE command to shift operations into 
reverse extended capabilities communications protocol, as 
shown in state 156. This attempt to try reverse operations 
occurs at a possible end of the data, or after a certain period 
of time of being in the forward state, in which case the 
controller operates the parallel port interface module 20 in 
reverse to pass data from the peripheral back to the host. If 
forward state operations 156 are being conducted in com- 
patibility mode protocol, any attempt to communicate with 
the peripheral will be done through negotiation to NIBBLE, 
as shown in circle 168. If the attempt to negotiate to 
NIBBLE as shown in 168 fails, then controller 126 reverts 
to the forward operation of state 156. In the event that the 
negotiation to NIBBLE of state 168 is successful, there will 
be NIBBLE communication from the peripheral to the host 
until the end of the data at which time the NIB__END state 
shown in circle 170 is extended, and operations of the 
controller revert to the forward state 156. 

The master state machine 128 shown in FIG. 6, is also 
shown in FIG. 9. It is the state machine that accomplishes 
the attempt to shift modes first into extended capabilities 
port protocol with run length encoded data, as shown in state 
152 of FIG. 8, and if that fails, then tries to shift into 
enhanced capability port protocol without run length 
encoded data, as shown in state 154 of FIG. 8, and finally 
into compatibility mode protocol for forward operations as 
shown in state 156 of FIG. 8. It also accomplishes the 
transitions to negotiations to the NIBBLE protocol and the 
DEVICE_ID protocol, also as shown in FIG. 8. 

As shown in FIG. 9, the starting, or default state 180 is for 
operation in the compatibility mode protocol. Upon receipt 
of a start signal, the master state machine waits for if 
compatibility mode protocol operations to finish in state 
182, and in state 184 will negotiate to the requested mode 
and upon completion of that mode shifts to termination 
sequence shown in state 186. 

FIG. 10 is the state transition diagram for compatibility 
mode protocol controller 130. Its default state 190 is idled. 
When enabled, it passes into a wait-for-data state 192, and 
when output data is available, it passes into send byte state 
194. 

FIG. 11 is a state transition diagram for NIBBLE con- 
troller 132. As shown in FIG. 9, the default state 200 is idle. 
When controller 126 initiates NIBBLE controller 132, and 
the peripheral has data ready, NIBBLE controller 132 tran- 
sitions to state 202, which is defined under IEEE 1284 
standards as host busy data available. When the host is 
ready, the NIBBLE controller transitions to state 204, host 
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ready data available, and then state 206, wherein a byte of 
data is retrieved. If there is more data to be sent from the 
peripheral, then the NIBBLE controller transitions back to 
state 204. 

State 208 exists when the host is busy and data is not 
available, in which case the NIBBLE controller transitions 
to reverse idle state 210 until it receives an interrupt from the 
peripheral indicating data is available, as shown in state 212, 
in which case the NIBBLE controller 132 transitions back to 
state 202, host busy, data available. 

FIG. 12 is a state transition diagram for ECP controller 
134. As with NIBBLE controller 132, the default state 220 
for ECP controller is idled. Upon the start command, it 
passes into the setup state 222 and then into the forward idle 
state 224. States 224 and 226 are the primary data out states 
for Extended Communications Protocol controller 134, 
wherein Extended Communications Protocol controller 134 
shifts between forward idle and sending bytes. If, during the 
course of sending data and shifting between states 224 and 
226, controller 126 signals a TRY_REVERSE command. 
Extended Communications Protocol controller 134 will 
transition through the forward idle state 224 to the transition 
to reverse state 230. 

From the transition to reverse state 230, the controller 
transitions to reverse idle state 232, and then alternately 
transfers back and forth between reverse idle 232 and the 
GET_BYTE 234 state, as data is transferred in reverse from 
the peripheral to the host. 

If the reverse data is run length encoded, then Extended 
Communications Protocol controller 134 transitions from 
the GET__BYTE 234 state to run length encoded reverse 
idle state 238, from where it transitions to GET_JBYTE state 
240, and then back to reverse idle state 234 as the counted 
bytes are retrieved and sent. 

While the preceding describes the automatic mode of 
operation under which parallel port interface module 20 is 
under automatic control of controller 136, as shown in FIG. 
8, parallel port interface module 20 is capable of being 
transitioned into a non-automatic, register mode of 
operation, as shown in state 172 of state transition diagram 
FIG. 8. In this mode of operation, the parallel port interface 
module is operating under direct host control. In practice, it 
has been found to be a much slower mode of operation, but 
is necessary for use with peripheral devices which use 
additional commands and communications protocols which 
are not standard to the specifications for these protocols. 

In register operation utilizing extended capabilities port 
language, ECP register mode controller 138 is utilized. A 
state transition diagram describing the operations of 
Extended Communications Protocol register mode control- 
ler 138 is shown and disclosed in FIG. 13. Its default state 
is idle. Upon transition of controller 126 to its register mode 
state 172 as shown in FIG. 8, and the receipt of a signal from 
the host to enable Extended Communications Protocol reg- 
ister mode controller 138, Extended Communications Pro- 
tocol register mode operation controller 138 shifts from the 
idle state 250 into either the forward idle state 252 or reverse 
idle state 256, depending upon whether or not the command 
from the host is transitioned to either forward or not forward. 
If the transition is to the forward idle state 252, then the 
Extended Communications Protocol register mode control- 
ler 138 shifts between the forward idle state 252 of the send 
byte state 254 as long as output data is available, or until a 
command is received from the host to transition from the 
forward idle state 252 to the reverse idle state 256. 

Upon transitioning to the reverse idle state 256, the 
Extended Communications Protocol register mode control- 
ler 138 will transition to GET_REVERSE byte state 258, 
and will alternately continue transitioning between reverse 
idle 256 and GET_REVERSE byte state 258 until the data 
is transferred. 
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If, however, the reverse data is run length encoded, then 
upon transitioning to the GET_REVERSE byte state 258, it 
will transition from there to run length encoded reverse idle 
state 260, and from there to get data bytes state 262, and then 
back to reverse idle state 256. 

In register mode operations, parallel port interface module 
20 is also capable of communicating with the peripheral 
using enhanced parallel port (EPP) protocols through 
enhanced parallel port register mode controller 136. FIG. 14 
discloses a state transition diagram 4 and enhanced parallel 
port register mode controller 136. Again, in this mode of 
operation, the parallel port interface module is under direct 
host control through controller 136, and begins in its initial 
idle state 270. Upon receipt of an enhanced parallel port 
protocol signal from the host, the enhanced parallel port 
register mode controller transitions to an idle state 272, from 
where it can transition to either send byte state 274 or GET 
byte state 276. 

While there is shown and described the present preferred 
embodiment of the invention, it is to be distinctly understood 
that this invention is not limited thereto but may be variously 
embodied to practice within the scope of the following 
claims. 

What is claimed is: 

1. A device connecting an external connection of a host 
device to an external connection of a peripheral device, 
comprising: 

a universal serial bus port interface adapted to receive a 
serial bit stream of data from the host using a Universal 
Serial Bus communications protocol; 

a controller adapted to extract data bytes from the serial 
bit stream of data and convert the extracted data bytes 
to comply with a IEEE 1284 communications protocol; 
and 

a parallel port interface adapted to transmit the converted 35 
data bytes to the peripheral device using the IEEE 1284 
communications protocol. 

2. A device according to claim 1 including: 

a memory storing a plurality of IEEE 1284 protocols in an 
hierarchical order; and 40 

a circuit for converting data bytes received in the Uni- 
versal Serial Bus communications protocol into data 
bytes in all of the IEEE 1284 communications proto- 
cols stored in said memory. 

3. A device according to claim 2 including a logic circuit 45 
adapted to select one of the plurality of IEEE 1284 com- 
munications protocols for transmitting data bytes to said 
parallel port interface. 

4. A device according to claim 1 including: 

a memory storing IEEE 1284 communications protocol 50 
information and Universal Serial Bus communications 
protocol information; and 

a circuit converting data bytes between the Universal 
Serial Bus communications protocol and the IEEE 
1284 communications protocol according to the IEEE 55 
1284 protocol information and the Universal Serial Bus 
communications protocol information stored in said 
memory. 

5. The device of claim 1 including: 

a serial register adapted to extract data from the serial bit 60 
stream from the host; 



a circuit adapted to identify the data as command data, 
interrupt request data or pay load data; 

a circuit adapted to convert command data from the 
Universal Serial Bus communications protocol into 
command data in the IEEE 1284 communications pro- 
tocol; 

a circuit configured to convert events in the 1284 com- 
munications protocol into interrupt request data for the 
Universal Serial bus communications protocol; and 

a circuit for converting payload data from the Universal 
Serial Bus communications protocol into payload data 
in the IEEE 1284 communications protocol. 

6. A signal converter located between a host and a 
peripheral device, comprising: 

a serial interface configured to receive from the host a 
serial bit stream using a serial bus communications 
protocol; 

a circuit adapted to extract data from the serial bit stream 
received from the host; 

a circuit adapted to convert the extracted data into a 
parallel data format; and 

a parallel interface configured to transmit the data con- 
verted into the parallel data format to the peripheral 
device using a parallel bus communications protocol, 
wherein the serial bus communications protocol com- 
prises a Universal Serial Bus protocol and the parallel 
bus communications protocol comprises a IEEE 1284 
parallel bus protocol. 

7. A signal converter located between a host and a 
peripheral device, comprising: 

a serial interface configured to receive from the host a 
serial bit stream using a serial bus communications 
protocol; 

a circuit adapted to extract data from the serial bit stream 
received from the host; 

a circuit adapted to convert the extracted data into a 
parallel data format; 

a parallel interface configured to transmit the data con- 
verted into the parallel data format to the peripheral 
device using a parallel bus communications protocol; 

a memory storing specifications and information for the 
parallel bus communications protocol used by the 
peripheral device and the serial bus communications 
protocol used by the host device; and 

a logic circuit adapted to use the stored specifications and 
information for converting data between the parallel 
bus communications protocol and the serial bus com- 
munications protocol. 

8. A signal converter according to claim 7 including: 

a logic circuit for determining different parallel bus com- 
munications protocols the peripheral device is capable 
of using; 

a logic circuit adapted to select one of the parallel bus 

communications protocols; and 
a logic circuit adapted to convert data bytes from the serial 

bus communications protocol to the selected one of the 

parallel bus communications protocols. 
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CERTIFICATE OF CORRECTION 
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DATED : April 17, 2001 

INVENTOR(S) : Watson et al. 

It is certified that error appears in the above-identified patent and that said Letters Patent is 
hereby corrected as shown below: 



Column 7. 

Line 52, "nack" should read NACK --; 
Column 8, 

Lines 18 and 39, "nack" should read » NACK --; 

Line 50, "filter 144 5 is provided. should read -filter 144 is provided ... -; 
Line 65, "hierarchle" should read -- hierarchical --; 

Column 9, 

Line 1, "hierarchle" should read « hierarchical --; 

Lines 48-49, "interface module tries" should read -- interface module 20 tries --; 
Column 11, 

Line 52, "waits for if compatibility" should read - waits for compatibility --. 
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